RUNTIME FLASH DEVICE DETECTION AND CONFIGURATION FOR FLASH 

DATA MANAGEMENT SOFTWARE 



TECHNICAL FIELD OF THE INVENTION 
[0001] The present invention relates generally to memory devices and in particular the 
present invention relates to Flash memory device drivers and Flash Memory data 
management software. 

BACKGROUND OF THE INVENTION 
[0002] Memory devices are typically provided as internal storage areas in the 
computer. The term memory identifies data storage that comes in the form of integrated 
circuit chips. There are several different types of memory used in modem electronics, one 
common type is RAM (random-access memory). RAM is characteristically found in use 
as main memory in a computer environment. RAM refers to read and write memory; that 
is, you can both write data into RAM and read data from RAM. This is in contrast to 
ROM (read-only memory), which permits you only to read data. Most RAM is volatile, 
which means that it requires a steady flow of electricity to maintain its contents. As soon 
as the power is turned off, whatever data was in RAM is lost. 

[0003] Computers almost always contain a small amount of ROM that holds 
instructions for starting up the computer. Unlike RAM, ROM generally cannot be written 
to by a user. An EEPROM (electrically erasable programmable read-only memory) is a 
special type non- volatile ROM that can be erased by exposing it to an electrical charge. 
EEPROM comprise a large number of memory cells having electrically isolated gates 
(floating gates). Data is stored in the memory cells in the form of charge on the floating 
gates. Charge is transported to or removed from the floating gates by specialized 
programming and erase operations, respectively. 

[0004] Yet another type of non- volatile memory is a Flash memory. A Flash memory 
is a type of EEPROM that can be erased in blocks instead of one byte at a time. A typical 
Flash memory comprises a memory array, which includes a large number of memory cells. 
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Each of the memory cells includes a floating gate field-effect transistor capable of holding 
a charge. The data in a cell is determined by the presence or absence of the charge in the 
floating gate. The cells are usually grouped into sections called "erase blocks." The . 
memory cells of a Flash memory array are typically arranged into a "NOR" architecture 
(each cell directly coupled to a bitline) or a "NAND" architecture (cells coupled into 
"strings" of cells, such that each cell is coupled indirectly to a bitline and requires 
activating the other cells of the string for access). Each of the cells within an erase block 
can be electrically programmed in a random basis by charging the floating gate. The 
charge can be removed from the floating gate by a block erase operation, wherein all 
floating gate memory cells in the erase block are erased in a single operation. 

[0005] Both RAM and ROM memory devices have memory cells that are typically 
arranged in an array of rows and columns. During operation, a row (page) is accessed and 
then memory cells can be randomly accessed on the page by providing column addresses. 
This access mode is referred to as page mode access. To read or write to multiple column 
locations on a page requires the external application of multiple column addresses. To 
increase access time, a burst mode access has been implemented. The burst mode uses an 
internal column address counter circuit to generate additional colunm addresses. The 
address counter begins at an externally provided address and advances in response to an 
external clock signal or a colunm address strobe signal. 

[0006] Many memory devices, in particular Flash memory devices, are utilized with 
specialized software handling and/or memory management routines, generally referred to 
as "drivers." The drivers are executed on the "host," typically a processor or memory 
controller, and allow the memory device(s) being utilized to be read from and written to by 
the host. In many systems the drivers also provide a layer of logical abstraction for the 
host. This is particularly the case with Flash memory devices, presenting the Flash 
memory device as a freely re-writeable general access memory device or mass storage 
device, such as a hardrive, a floppy disk, or other non- volatile machine-usable storage 
device. The drivers, as part of the Flash memory device hardware abstraction, typically 
also manage the Flash memory devices utilizing internal management routines; scheduling 
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erase blocks to be erased, managing bad erase blocks, protecting and unprotecting erase 
blocks, and load leveling the Flash memory device. 

[0007] The driver and/or memory management routines are generally supplied by the 
memory manufacturer to the end-user or device manufacturer. These driver routines are 
typically supplied in a source code format or as a linkable library and as such must be 
compiled into the operating system or overall code executing on the device. Self 
contained and separately loadable drivers are also possible, but are typically not utilized in 
embedded processor devices. 

[0008] The software routines and drivers that operate computer-based devices are often 
collectively referred to as firmware or ROM after the non-volatile ROM machine-usable 
storage device that such routines have historically been stored in. It is noted that such 
firmware or ROM routines are stored on a variety of machine-usable storage mediums or 
firmware storage mediums that include, but are not limited to, a non-volatile Flash 
memory, a ROM, an EEPROM, a one time programmable (OTP) device, a complex 
programmable logic device (CPLD), an application specific integrated circuit (ASIC), a 
magnetic media disk, etc. 

[0009] A problem with computer-based or embedded processor systems is the multiple 
differing memory devices that may be potentially utilized with these devices over their 
lifetimes of use, or even within a production run of a device. These memory devices may 
differ from memory manufacturer to memory manufacturer, or from part to part; even if 
the memory has similar electrical connections or interfaces. As a result, the driver and 
management software generally differs for each differing type of memory device the 
manufacturer incorporates into their system. This is particularly the case for Flash 
memory devices, where a specialized driver is needed to interface with and properly 
operate the Flash memory. In addition, many Flash memory devices are formatted to 
resemble mass storage devices, such as magnetic disks, and are not utilized as a general 
access memory. These specialized Flash memory drivers allows the system to read, erase, 
program, and manage the erase blocks of a Flash memory device and can be unique to the 
Flash memory device or manufacturer. In many cases, because the Flash memory device 
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cannot be accessed without use of the Flash memory driver, the driver software is stored 
on another non-volatile machine-usable medium (such as a Boot ROM or a magnetic disk) 
and is loaded at system initialization. 

[0010] As these memory device drivers are typically compiled or loaded into the 
operating system or application routine (herein operating system) that operates the 
computer based system, the manufacturers must produce, test, and maintain multiple 
versions of their operating system software with differing drivers to support all the possible 
memory devices utilized with the system. This can lead to problems in maintaining these 
systems or devices, as the end user or service personnel must often update the software of 
the system when a memory device is updated or replaced, or be aware of the types of 
memory devices in the system when the system software itself is updated. If they do not 
correctly match the software to the memory device being utilized the system may be 
rendered inoperable. 

[0011] One other way in which this problem of supporting multiple differing memory 
types has been solved in the past has been by compiling multiple different drivers into the 
operating system. This allows the operating system to drive any likely memory device of a 
set likely to be utilized. Unfortunately, the operating system will typically not 
automatically select the appropriate driver and must be hand configured to use appropriate 
driver for the memory device being utilized. Additionally, the resulting software, 
containing multiple separate driver routines, is typically much larger than a single driver 
executable and thus is not suitable for many embedded devices where resources and non- 
volatile (boot ROM) storage space is limited. Further, in many of these multiple driver 
cases the drivers are implemented in a generic and inefficient manner, so as to apply to as 
many memories types as possible; trading operating efficiency for wider applicability and a 
smaller code size. 

[0012] For the reasons stated above, and for other reasons stated below which will 
become apparent to those skilled in the art upon reading and understanding the present 
specification, there is a need in the art for alternative methods of detecting and driving 
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different memory devices in computer based systems and, in particular, Flash memory 
devices. 

SUMMARY 

[0013] The above-mentioned problems with memory devices, Flash memory devices, 
software drivers, and other problems are addressed by the present invention and will be 
understood by reading and studying the following specification. 

[0014] The various embodiments relate to software drivers that can support multiple 
differing memory devices, in particular, differing Flash memory devices, by being 
internally re-configurable to match the driving and management requirements of the 
particular memory device. This allows for a more limited number of operating system 
versions, or even just a single version, to be produced and maintained for a given system 
by the manufacturer. This also reduces the possibility of misconfiguration of the 
system/device by the inadvertent updating or programming of the wrong operating system 
version by an end user or service personnel. The resulting driver routine and/or operating 
system is also typically smaller than operating systems/drivers that compile in multiple 
separate drivers, and yet as efficient as a driver specifically directed at a single memory 
device, being internally configured to the memory device. In one embodiment of the 
present invention, the software driver automatically configures itself by querying the 
memory device for a device ID and/or manufacturer code or by detecting a specific 
characteristic of the memory device being driven. In another embodiment, a table contains 
driver configurations for specific memory device types, data models, and/or memory 
device usage. In further embodiment, the configuration table is updateable. 

[0015] For one embodiment, the invention provides a method of operating a memory 
device driver comprising, querying at least one memory device to discover the memory 
type, and configuring the driver to access the at least one memory device according to the 
discovered memory type. 

[0016] For another embodiment, the invention provides a method of operating a 
system comprising querying at least one Flash memory device coupled to a host to 
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discover the memory type, and configuring a driver routine executing on the host to access 
the at least one Flash memory device according to the discovered memory type. 

[0017] For yet another embodiment, the invention provides a system comprising at 
least one Flash memory device, and a host coupled to the at least one Flash memory 
device, wherein the host is adapted to query the at least one Flash memory device and 
configure a driver routine to access the at least one Flash memory device in response to the 
query. 

[0018] For a further embodiment, the invention provides a machine-usable medium, 
the machine-usable medium containing a software routine for causing a processor to 
execute a method. The method comprising querying at least one Flash memory device to 
discover the memory type, and configuring a driver to access the at least one Flash 
memory device according to the discovered memory type. 

[0019] Further embodiments of the invention include methods and apparatus of 
varying scope. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0020] Figure 1 is a simplified block diagram of a system containing a Flash memory 
device in accordance with an embodiment of the present invention. 

[0021] Figure 2 is a simplified block diagram of a system containing a Flash memory 
subsystem in accordance with an embodiment of the present invention. 

[0022] Figures 3 A and 3B are simplified block diagrams of Flash memory arrays in 
accordance with an embodiment of the present invention. 

[0023] Figure 4 is a flowchart diagram detailing operation of an embodiment of the 
present invention. 

DETAILED DESCRIPTION 
[0024] In the following detailed description of the invention, reference is made to the 
accompanying drawings that form a part hereof, and in which is shown, by way of 
illustration, specific embodiments in which the invention may be practiced. In the 
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drawings, like numerals describe substantially similar components throughout the several 
views. These embodiments are described in sufficient detail to enable those skilled in the 
art to practice the invention. Other embodiments may be utilized and structural, logical, 
and electrical changes may be made without departing from the scope of the present 
invention. The following detailed description is, therefore, not to be taken in a limiting 
sense, and the scope of the present invention is defined only by the appended claims and 
equivalents thereof. 

[0025] Embodiments of the present invention include general memory drivers. Flash 
memory drivers, memory device identification and querying methods that can support 
multiple differing memory devices, in particular, differing Flash memory devices, by being 
internally re-configurable to match the driving and management requirements of the 
particular memory device. This allows for a more limited number of operating system 
versions/target image, or even just a single version, to be produced and maintained for a 
given system by the manufacturer. This also reduces the possibility of misconfiguration of 
the system/device by the inadvertent updating or programming of the wrong operating 
system version by an end user or service personnel. The resulting driver routine and/or 
operating system is also typically smaller than operating systems/drivers that compile in 
multiple separate drivers, and yet as efficient as a driver specifically directed at a single 
memory device, being internally configured to the memory device. In one embodiment of 
the present invention, the software driver automatically configures itself by querying the 
memory device for a device ID and/or manufacturer code or by detecting a specific 
characteristic of the memory device being driven. In another embodiment, a table contains 
driver configurations for specific memory device types, data models, and/or memory 
device usage. In further embodiment, the configuration table is updateable. 

[0026] As stated above, the two common types of Flash memory array architectures 
are the "NAND" and "NOR" architectures, so called for the similarity each basic memory 
cell configuration has to the corresponding logic gate design. In the NOR array 
architecture, the floating gate memory cells of the memory array are arranged in a matrix 
similar to RAM or ROM. The gates of each floating gate memory cell of the array matrix 
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are coupled by rows to word select lines (word lines) and their drains are coupled to 
column bit lines. The source of each floating gate memory cell is typically coupled to a 
common source line. The NOR architecture floating gate memory array is accessed by a 
row decoder activating a row of floating gate memory cells by selecting the word line 
coupled to their gates. The row of selected memory cells then place their stored data 
values on the column bit lines by flowing a differing current if in a programmed state or 
not programmed state from the coupled source line to the coupled column bit lines. A 
column page of bit lines is selected and sensed, and individual data words are selected 
from the sensed data words from the column page and communicated from the Flash 
memory. 

[0027] A NAND array architecture also arranges its array of floating gate memory 
cells in a matrix such that the gates of each floating gate memory cell of the array are 
coupled by rows to word lines. However each memory cell is not directly coupled to a 
source line and a column bit line. Instead, the memory cells of the array are arranged 
together in strings, typically of 8, 16, or more each, where the memory cells in the string 
are coupled together in series, source to drain, between a conunon source line and a 
colunm bit line. This allows a NAND Flash array architecture to have a higher memory 
cell density than a comparable NOR Flash array, but with the cost of a generally slower 
access rate and progranmiing complexity. 

[0028] A NAND architecture floating gate memory array is accessed by a row decoder 
activating a row of floating gate memory cells by selecting the word select line coupled to 
their gates. In addition, the word lines coupled to the gates of the unselected memory cells 
of each string are also driven. However, the unselected memory cells of each string are 
typically driven by a higher gate voltage so as to operate them as pass transistors and 
allowing them to pass current in a manner that is unrestricted by their stored data values. 
Current then flows from the source line to the column bit line through each floating gate 
memory cell of the series coupled string, restricted only by the memory cells of each string 
that are selected to be read. Thereby placing the current encoded stored data values of the 
row of selected memory cells on the column bit lines. A column page of bit lines is 
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selected and sensed, and then individual data words are selected from the sensed data 
words from the column page and communicated from the Flash memory. 

[0029] Because all the cells in an erase block of a Flash memory device must be erased 
at once, one cannot directly rewrite a Flash memory cell without first engaging in a block 
erase operation. Erase block management (EBM)/Flash data management, which can be 
under the control of an internal state machine of the memory device or part of the driver 
software/memory management software, provides an abstraction layer for this to the host 
(typically a processor or an external memory controller), allowing the Flash device to 
appear as a freely rewriteable device. EBM duties also include, but are not limited to, 
managing the logical address to physical erase block translation mapping for reads and 
writes, the assignment of erased and available erase blocks for utilization, and the 
scheduling erase blocks that have been used and closed out for block erasure. Erase block 
management also allows for load leveling of the internal floating gate memory cells to help 
prevent write fatigue failure. Write fatigue is where the floating gate memory cell, after 
repetitive writes and erasures, no longer properly erases and removes charge from the 
floating gate. Load leveling procedures increase the mean time between failure of the 
erase block and Flash memory device as a whole. 

[0030] Because of the complexity of the tasks of managing and interfacing to the 
memory device(s), the driver software/memory management software is typically 
segmented into a data manager layer (that is responsible for the higher level interfacing 
such as erase block management and address/logical device abstraction and can include a 
linear data manager and a segment data manager for managing linear blocks or data and 
data packets respectively) and a low level device driver layer (that is responsible for the 
interfacing, conmiand set sequences, and timing of interfacing to the specific memory 
device). These driver software/memory management software layers typically interface 
between each other by means of a defined "application interface" (API) that allows the 
differing layers to function without direct knowledge or control of the other layers. 

[0031] Additionally, there is sometimes a further driver layer between the operating 
system/application, called the file manager. The file manager is responsible for managing 
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the data entities (typically separate data files or structures) and the format of the memory 
device. The file manager (or in some cases, the data manager) can tailor its operation of 
the memory device to the device's storage usage by the operating system/application. The 
storage usage or access patterns of the memory device are called the "data model" of the 
memory use and can be used to tailor/optimize the memory's utilization by the 
application/system it is installed in. For example, a digital camera would require large data 
file storage that was frequently erased and reprogranmied, whereas a cell phone would 
typically require storage of many small data entities that would be frequently accessed but 
seldom changed. 

[0032] In many modem Flash memory device implementations, the host interface and 
erase block management routines additionally allow the Flash memory device to appear as 
a read/write mass storage device (i.e., a magnetic disk) to the host. One such approach is 
to conform the interface to the Flash memory to be identical to a standard interface for a 
conventional magnetic hard disk drive allowing the Flash memory device to appear as a 
block read/write mass storage device or disk. This approach has been codified by the 
Personal Computer Memory Card International Association (PCMCIA), Compact Flash 
(CF), and Multimedia Card (MMC) standardization conmiittees, which have each 
promulgated a standard for supporting Flash memory systems or Flash memory "cards" 
with a hard disk drive protocol. A Flash memory device or Flash memory card (including 
one or more Flash memory array chips) whose interface meets these standards can be 
plugged into a host system having a standard DOS (Disk Operating System) or compatible 
operating system with a Personal Computer Memory Card International Association - 
Advanced Technology Attachment (PCMCIA- ATA) or standard ATA interface. Other 
additional Flash memory based mass storage devices of differing low level formats and 
interfaces also exist, such as Universal Serial Bus (USB) Flash drives or Sony 
MemoryStick. 

[0033] Many of the modem computer operating systems, such as DOS, were 
developed to support the physical characteristics of hard drive structures; supporting file 
structures based on heads, cylinders and sectors. The DOS software stores and retrieves 
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data based on these physical attributes. Magnetic hard disk drives operate by storing 
polarities on magnetic material. This material is able to be rewritten quickly and as often 
as desired. These characteristics have allowed DOS to develop a file structure that stores 
files at a given location which is updated by a rewrite of that location as information is 
changed. Essentially all locations in DOS are viewed as fixed and do not change over the 
life of the disk drive being used therewith, and are easily updated by rewrites of the 
smallest supported block of this structure. A sector (of a magnetic disk drive) is the 
smallest unit of storage that the DOS operating system supports. In particular, a sector has 
come to mean 512 bytes of information for DOS and most other operating systems in 
existence. Flash memory systems that emulate the storage characteristics of hard disk 
drives are preferably structured to support storage in 512 byte blocks along with additional 
storage for overhead associated with mass storage, such as ECC (error correction code) 
bits, status flags for the sector or erase block, and/or redundant bits. 

[0034] Figure 1 shows a simplified diagram of a system 128 incorporating a Flash 
memory device 100 of the present invention coupled to a host 102, which is typically a 
processing device or memory controller. Flash driver routines can be stored in internal 
non-volatile memory that is incorporated in some hosts (typically embedded processors 
with internal memory arrays) or in a secondary machine-usable memory device (such as a 
boot ROM) coupled to the host. The Flash memory device 100 has an address interface 
104, a control interface 106, and a data interface 108 that are each coupled to the 
processing device 102 to allow memory read and write accesses. Internal to the Rash 
memory device, a control state machine 1 10 directs the internal operation; managing the 
Flash memory array 112 and updating RAM control registers and non- volatile erase block 
management registers 114. The RAM control registers and tables 1 14 are utilized by the 
control state machine 1 10 during operation of the Hash memory device 100. The Flash 
memory array 1 12 contains a sequence of memory banks or segments 1 16. Each bank 1 16 
is organized logically into a series of erase blocks (not shown). Memory access addresses 
are received on the address interface 104 of the Flash memory device 100 and divided into 
a row and column address portions. On a read access the row address is latched and 
decoded by row decode circuit 120, which selects and activates a row page (not shown) of 
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memory cells across a selected memory bank. The bit values encoded in the output of the 
selected row of memory cells are coupled from a local bitline (not shown) to a global 
bitline (not shown) and detected by sense amplifiers 122 associated with the memory bank. 
The column address of the access is latched and decoded by the column decode circuit 124. 
The output of the colunm decode circuit 124 selects the desired column data from the 
internal data bus (not shown) that is coupled to the outputs of the individual read sense 
amplifiers 122 and couples them to the data buffer 126 for transfer from the memory 
device 100 through the data interface 108. On a write access the row decode circuit 120 
selects the row page and column decode circuit 124 selects write sense amplifiers 122. 
Data values to be written are coupled from the data buffer 126 via the internal data bus to 
the write sense amplifiers 122 selected by the column decode circuit 124 and written to the 
selected floating gate memory cells (not shown) of the memory array 1 12. The written 
cells are then reselected by the row and column decode circuits 120, 124 and sense 
amplifiers 122 so that they can be read to verify that the correct values have been 
programmed into the selected memory cells. 

[0035] Figure 2 is a simplified diagram of another system 200 that incorporates a Flash 
memory subsystem 204 and associated Flash driver software routines of an embodiment of 
the present invention. In the system 200 of Figure 2, the Flash memory subsystem 204, 
such as a memory system or Flash memory card, is coupled to a processor 202 with a 
synchronous interface having an address 206, control 208, and data bus 210. Internal to 
the Flash memory system 200, a memory controller 212 directs internal operation of the 
Flash memory system 200; managing the Flash memory devices 214, directing data 
accesses, updating internal control registers and tables (not shown), and/or directing 
operation of other possible subsystems (not shown) of the Flash memory system 200. The 
memory controller 212 is coupled to and controls one or more Flash memory devices 214 
via an internal bus 236. Each Flash memory device 214 contains a sequence of erase 
blocks (not shown) in an internal memory array 216. It is noted that other architectures of 
Flash memory systems 200, external interfaces 206, 208, 210, and manners of coupling the 
memory controller 212 to the Flash memory devices 214, such as directly coupled 
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individual control busses and signal lines, are possible and should be apparent to those 
skilled in the art with benefit of the present disclosure. 

[0036] Memory devices are typically coupled to a device select line and/or placed in a 
specific range of address location(s) in the memory range (also known as a memory map) 
of the host they are coupled to. With device select lines, to access a specific memory 
device the host activates the device select line coupled to the memory device and begins 
addressing its memory locations. With a memory mapped memory device, the address 
location of the selected memory device is addressed directly to communicate with the 
memory device. In many cases these two techniques are combined, requiring host memory 
accesses to activate a device select line and address the access to the base address of the 
memory device in the host's memory range. 

[0037] Many modem Flash memories devices include an address that when issued a 
command (the designated address of the Flash memory is written to with an appropriate 
data value) the memory device type identification or other vendor information (the 
response) is then read from the device from the same address location or other designated 
memory locations. Typically, in these devices other conmiands can also request device 
timing and voltage information, device geometry information, or user/vendor defined 
information. 

[0038] One such interface is called a "conmion Flash interface" (CFI) and provides 
certain simple low level conmiunication with the Flash memory for identifying the Flash 
memory device. In utilizing a Flash memory that conforms to the CFI standard, a special 
query is sent to a designated address of the Flash memory and the response is read from the 
device in other designated memory locations. One CFI conwnand requires the Flash 
memory device to respond with its memory device type identification or other vendor 
information. The CFI commands can also request device timing and voltage information, 
device geometry information, or user/vendor defined information. 

[0039] Additionally, some Flash memories include special purpose "protection" 
registers. Protection registers are limited-size non-volatile storage areas that are separate 
from the erase blocks of the Flash memory. Protection registers are typically utilized for 
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storage of special purpose device identifiers and/or security codes that are associated with 
the Flash memory device and/or the data contents of its erase blocks. Once programmed, 
protection registers can be locked by the programming of "lock bits" that are associated 
with each individual protection register and/or protection register segment. There usually 
are 128 bits of protection register storage in a typical Flash memory device. Typically, one 
half of the Flash memory protection register, a 64 bit "factory" segment, is programmed 
and locked by the memory chip manufacturer with a device ID that identifies the Flash 
memory. The remaining half, the original equipment manufacturer or "OEM*' segment, 
can be programmed and locked by the end-user or the manufacturer of a device or system 
that incorporates the Flash memory device. This user-programmable portion of the Flash 
memory is typically utilized to implement security schemes, simplify manufacturing, 
and/or reduce system maintenance. 

[0040] Figure 3 A shows a simplified block diagram of a Flash memory array 300 of an 
embodiment of the present invention. In Figure 3A, a Flash memory array 300 contains a 
protection register 302 and a sequence of erase blocks 304. Each erase block 304 contains 
a series of sectors 306 that are typically each written to a single row of the memory array 
300 and include a user data space or area and an associated control or overhead data space 
or area. The control/overhead data space contains overhead information for operation of 
the sector it is associated with. Such overhead information typically includes, but is not 
limited to, erase block management (EBM) data, sector status information, or an error 
correction code (ECC, not shown). The user data space in each sector 306 is typically one 
or more multiples of 512 bytes long (depending on memory array 300 row size), wherein 
one or more logical/operating system (OS) sectors of 512-bytes or multiple logically 
addressed data words can be stored on the row or sector 306. In a typical Flash memory 
array 300 each erase block 304 typically contains 64, 128, or more sectors 306. Each new 
512 bytes of user data and its associated overhead data are together written into an 
available erase block sector 306 (i.e.. User data A with Overhead data A within a single 
erase block sector 306) as the user data arrives at the Flash memory array 300. User data is 
typically written sequentially into the sectors 306 of an erase block 304 until it is filled. 
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[0041] The protection register 302 of the Flash memory array 300 is separate from the 
erase blocks 304 and is separately addressable. There are 128 bits of protection register 
storage with one half, a 64-bit "factory" segment 308, programmed and locked by the 
memory chip manufacturer with a device ID that identifies the Flash memory device the 
array 300 is incorporated in. The remaining half, the original equipment manufacturer or 
"OEM" segment 310, is progranmied and locked by the end-user or the manufacturer of a 
device or system that incorporates the Flash memory device with the array 300. Typically 
this protection array is accessible without the need of a software driver, allowing it to be 
utilized to identify the Flash memory device during initialization. 

[0042] Figure 3B shows a simplified block diagram of another Flash memory array 
350 of an embodiment of the present invention. In Figure 3B, a Flash memory array 350 
contains a sequence of data words 354 addressed from 0 to N 352. A device ID 358 that 
identifies the Flash memory device type is stored at address 0 356. 

[0043] It is noted that other manners of identifying memory devices by querying 
interfaces, reserved memory locations, protection registers, and other architecture features 
are possible and should be apparent to those skilled in the art with benefit of the present 
disclosure. 

[0044] Software driver embodiments of the present invention query interfaces, 
reserved memory locations, protection registers, and other architecture features, to 
determine the type, size, manufacturer, and other pertinent identifying information of the 
memory device(s) that are coupled to the system. The driver embodiments then configure 
themselves to match the discovered memory device(s) by altering the internal operation 
parameters, device command sequences, and/or memory management routines they utilize. 
In an alternative embodiment, the type memory device(s) can be discovered by reading a 
configuration stored separate from the memory devices themselves, such as in a non- 
volatile storage location of an embedded processor, or in a boot ROM. 

[0045] In one embodiment of the present invention, the software driver matches the 
discovered memory device type to an entry in a memory type data table. Each memory 
type data table contains the file manager, data manager configuration, and/or low level 
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driver configuration to configure the driver software for the detected memory type. The 
data table may contain information such as memory command sequences, device 
geometry, timing configuration, load leveling configuration, file formats, device 
formatting, block erasure sequences, and/or memory manufacturer specific commands. 

[0046] In another embodiment, the data table contains memory data models for the 
intended usage of the memory device. In one embodiment, the data model is designated by 
the intended usage by the operating system/application. In yet another embodiment, the 
data table entry for the specific data model or usage specific memory device 
parameter/configuration is specified by end-user or vendor configuration data stored in the 
memory device itself, such as in an OEM protection register or a vendor specified CFI 
configuration parameter. 

[0047] In further embodiment of the present invention, the software driver is 
updateable without requiring updating of the driver itself, or recompilation, by the 
updating of the configuration data table(s) to cover new or differing types of memory 
devices. This allows the driver and/or operating system that incorporates the driver to be 
updated for new memory devices or fix driver problems without requiring its 
recompilation, testing, and issuance of new driver/operating system versions. This is 
particularly the case where the new memory type is similar to, or of the same device 
family, as an existing supported memory type. In another embodiment, the driver is 
extensible to a new memory type by small changes to its component sections, for example, 
the low level driver. 

[0048] Figure 4 shows a simplified flowchart 400 of a method of operating a memory 
device driver in accordance with an embodiment of the present invention. In Figure 4, the 
memory device driver is initialized 402 by being invoked by the operating system during 
system initialization or power up. The device driver then reads 404 the memory 
configuration information or queries the memory device ID and configures 406 its internal 
operation parameters, device command sequences, and/or memory management routines to 
match the identified memory device(s). The device driver then ends 408 
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configuration/memory device identification process and begins normal operation of the 
device driver. 

[0049] It is noted that systems, methods, and configurable memory device drivers of 
other embodiments of the present invention are possible and should be apparent to those 
skilled in the art with the benefit of the present invention. 

CONCLUSION 

[0050] Software memory device driver has been described that can support multiple 
differing memory devices, in particular, differing Flash memory devices, by being 
internally re-configurable to match the driving and management requirements of the 
particular memory device. This allows for a more limited number of operating system 
versions, or even just a single version, to be produced and maintained for a given system 
by the manufacturer. This also reduces the possibility of misconfiguration of the 
system/device by the inadvertent updating or programming of the wrong operating system 
version by an end user or service personnel. The resulting driver routine and/or operating 
system is also typically smaller than operating systems/drivers that compile in multiple 
separate drivers, and yet as efficient as a driver specifically directed at a single memory 
device, being internally configured to the memory device. In one embodiment of the 
present invention, the software driver automatically configures itself by querying the 
memory device for a device ID or manufacturer code or by detecting a specific 
characteristic of the memory device being driven. In another embodiment, a table contains 
driver configurations for specific memory device types, data models, and/or memory 
device usage. In further embodiment, the configuration table is updateable. 

[0051] Although specific embodiments have been illustrated and described herein, it 
will be appreciated by those of ordinary skill in the art that any arrangement that is 
calculated to achieve the same purpose may be substituted for the specific embodiments 
shown. Many adaptations of the invention will be apparent to those of ordinary skill in the 
art. Accordingly, this application is intended to cover any adaptations or variations of the 
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invention. It is manifestly intended that this invention be limited only by the following 
claims and equivalents thereof. 
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